In recent years, a design concept of software called service oriented architecture (SOA) is drawing attention with progress of distributed computing technology. In SOA, program components, each providing a bundle of general functions, are operated independently. The functions are presented outside as a service. A target system is built with these services cooperating with each other. The cooperation between the program components is specified simply with an interface of the service provided by each program component. Therefore, independence, maintainability, and reusability of each program component are improved.
As a concrete method for obtaining software according to the concept of SOA, service component architecture (SCA) is known.
SCA is the method for obtaining software in which a system is built focusing on a component (or component element) which is an instance of a program component and a service (or service element) which is a function provided by the component. As other elements than a component and a service, a reference (or reference element), a wiring (or wiring element), a property (or property element) and a composite (or composite element) or the like are also used.
The detailed specification of SCA is described in non-patent literature 1, for example.
Here, taking SCA as an example, a specification of such program modularization which has high reusability in a method for obtaining a system by combination of program components will be described.
FIG. 35 is a diagram showing elements defined in SCA.
In FIG. 35, a component 301 is an element that specifies an instance of an executable program component. The component 301 includes implementation of a program component and setting required for the execution thereof. For example, the implementation is specified by a program described using a language such as Java (registered trademark) or C++, and the setting is specified by an element such as a service 302, a reference 303, and a property 304 of the component 301. Here, the service 302 is an element that specifies a function provided by the component 301. The reference 303 is an element that specifies the service consumed by the component 301. The property 304 is an element that specifies a variable and a value thereof used by the component 301 when it is executed.
A composite 310 is an element that specifies a combination of these elements. The composite 310 may include a plurality of components 301 and wirings 315, 316 in the interior thereof. The wirings 315, 316 are elements that specify a connection between an element requiring a service and an element providing the service. Cooperation among a plurality of program components, which are the characteristics of SOA, is expressed by connecting the reference 303 and the service 302 with a wiring between components 301.
The composite 310 itself may be reused for an implementation of other components (the composite 310 can use an instance of other composite 310 as a component).
The composite 310 may include a service 312 in the interior thereof. By doing this, it is possible to specify a service that can be provided when the composite 310 is instantiated as a component. The service 312 included in the composite is provided by the service 302 of the component 301 included in the composite 310. These services 302 and 312 are connected by the wiring 315 in the composite 310.
The composite 310 may include a reference 313 in the interior thereof. By doing this, it is possible to specify a service consumed when the composite 310 is instantiated as a component. The reference 313 is used when the service consumed by the component 301 included in the composite 310 is provided outside the composite 310. In this case, the reference 303 of the component 301 that consumes the service and the reference 313 of the composite 310 are connected by the wiring 316 in the composite 310.
An interface may be specified for the service 312 and the reference 313 of the composite 310. By doing this, it is possible to control application of the wiring, considering functionality that can be provided by the service 312 and functionality required by the reference 313.
The composite 310 may include a property 314 in the interior thereof. By doing this, it is possible to specify a property that can indicate a value when the composite is instantiated as a component. The property 314 included in the composite can be referred from the component 301 as a value of the property 304 of the component 301 included in the composite 310. By doing this, it is possible to set a value of the property 314 of the component 301 included in the composite 310 on a component using the composite 310 as an implementation. A type of a value may be specified for the property 314. By doing this, it is possible to control reference setting is permitted or not, considering compatibility between the type of a value required by the referring property and the type of a value provided by the referred propriety.
The mechanism to inject a function or data on which a program component depends from the outside, such as the mechanism of a reference or referring to a property described above, is generally called dependency injection (DI). The dependency injection is drawing attention as a method for improving a reusability of a program component, particularly in recent years.
In the method for obtaining a system by combination of program components such as SCA, the target system can be effectively built, based on many general and fine-grained program components, by gathering components or services as composites and further gathering the composites as higher order composites, using the mechanism of DI.
By the way, in the method for obtaining a system by the combination of program components, generally, the necessary elements are not always stored in the suitable composite from the beginning of the design. It is necessary to perform refactoring and to adjust locations of the elements included in a program component as same as other programming methods.
For example, a composite A that provides a service receiving two integers and displaying the sum of them with easily viewable format to a user is considered. The composite A has a component S that calculates the sum and a component P that displays it with easily viewable format to the user. Here, it is found that a similar function can be provided for other calculations by changing the component S into another component, for example, a component M for multiplication. In this case, the reusability of the composite A can be improved by extracting a part that uses the service of the component S in the composite A as a reference and changing the composite A into a composite that displays a calculated result with easily viewable format in combination with an arbitrary calculation component.
However, in case the composite including the component to be relocated is already used as an implementation of a component in other composite, or in case the component to be relocated is connected with other services or references, the user needs to perform adjustments of elements other than the component to be relocated, such as adding a component and adding a wiring for connecting the added component, so that the refactoring does not affect the functionality of the whole system.
Note that, in patent literature 1, as a related art in a technology regarding the refactoring support in system development using the combination of program components, a method removing a code of a function that is not used is described.